Christopher James Huff wrote:

>> > that could be used for actual rendering.
>> >
>> ?! You mean I should buy 256 GigaB RAM?
> 
> No...just enough to hold what you need to render, and use some
> intelligence in setting up the scene. 
>
Just tell my why I should use "intelligence" doing complicated 
viewport and culling calculations (think of animations) which require 
a separate mesh include file for each frame if the problem could be 
delt with in an easier and (as I think) more elegant way?

> A high resolution mesh of an
> entire planet is ridiculous when you are viewing it from orbit. 
>
(You need 1 million triangles for the visible half of a planet from orbit 
(height is scaled by some factor to make it look more interesting) when 
you look at it at diameter = screen height. Medium-sized, I guess...)

> If you are close enough to see details, you don't need anything close 
> to the entire planet.
> 
Correct. Did I doubt that?

> A binary mesh format would make loading
> high-res meshes faster.
> 
...and smaller on HD. 

>> But the more general solution would be some support for auto-generated
>> "artificial" complexity in meshes (added at render time).
> 
> Auto-generated mesh complexity is not a bad idea, but doing it at render
> time involves inefficiencies that could make it slower than just doing
> it on the mesh and storing the higher resolution version. 
>
There are 3 major advantages: 
- may be faster than mesh2 because we save parse time. 
- uses less memory while not requiring the user to do complicated 
  viewport and grid size calculations. 
  This means, if you use a very deep scene (fly along a valley), 
  it would produce nice scenery from a low/med-resolution mesh 
  with constant grid size. 
- And, as you mentioned: 
> it only does it to the parts of the mesh where it is needed...
 
>> Or, maybe, support for "mesh textures" for primitive objects (i.e.
>> height fields on top of sphere, cylinder/cone, torus)
> 
> There's macros that make spherical and cylinderical height fields. Not
> toroidal or cubical though.
> 
IIRC these macros are just creating a mesh from the data. 
And a cube is not needed. One can use 6 height fields instead. 

Wolfgang

Post a reply to this message